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Art Unit: 2162 

DETAILED ACTION 

1 . The Office withdraws the previous rejections of the claims under 35 USC § 1 12-2 nd 
paragraph, in light of the amendment. However, the Office maintains the previous rejections of 
the claims under 35 USC § 103(a), in light of the amendment. 

Response to Arguments 

2. Applicant's response to the RFI under 37 CFR § 1 . 105 is compliant and made of record. 

3. Applicant's arguments filed 7/1/2008 have been fully considered but they are not 
persuasive. 

Regarding the previous rejection of the claims under 35 USC § 103(a), Applicant asserts 
on pages 9-11 that Applicant has reviewed the parent Application (09/866101) of the cited 
Hellman reference and cannot find support for the passage relied upon in Hellman. 

The Office respectfully disagrees. The parent Application (09/866101) of Hellman 
discusses the transformation between data source models at page 32 lines 23-27, for example. 
Therefore the reliance on the priority date of the Hellman reference was proper. 
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Regarding the previous rejection of independent claims 1 and 10 (and dependent claims 
3-4 and 11-16) under 35 USC § 103(a), Applicant asserts on pages 1 1-12 that the references do 
not teach the recited limitations for the reasons set forth above regarding the Hellman reference. 

The Office respectfully disagrees, noting that the references as a whole teach the recited 
claim language. The Office counter-asserts the rationale set forth above concerning the reliance 
upon the Hellman priority date. 

Regarding the previous rejection of claims 18 and 20-21 under 35 USC 103(a), Applicant 
asserts on pages 12-13 that the references do not teach the recited limitations for the reasons set 
forth above regarding the Hellman reference. 

The Office respectfully disagrees, noting that the references as a whole teach the recited 
claim language. The Office counter-asserts the rationale set forth above concerning the reliance 
upon the Hellman priority date. 

Regarding the previous rejection of claims 5-9 under 35 USC § 103(a), Applicant asserts 
on pages 13-14 that the references do not teach the recited limitations for the reasons set forth 
above regarding the Hellman reference. 

The Office respectfully disagrees, noting that the references as a whole teach the recited 
claim language. The Office counter-asserts the rationale set forth above concerning the reliance 
upon the Hellman priority date. 
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Regarding the previous rejection of claims 22-26 under 35 USC § 103(a), Applicant 
asserts on pages 14-15 that the references do not teach the recited limitations for the reasons set 
forth above regarding the Hellman reference. 

The Office respectfully disagrees, noting that the references as a whole teach the recited 
claim language. The Office counter-asserts the rationale set forth above concerning the reliance 
upon the Hellman priority date. 

It is further noted that any citation to specific, pages, columns, lines, or figures in the 
prior art references and any interpretation of the references should not be considered to be 
limiting in any way. A reference is relevant for all it contains and may be relied upon for all that 
it would have reasonably suggested to one having ordinary skill in the art. In re Heck, 699 F.2d 
1331, 1332-1333, 216 USPQ 1038, 1039 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 
1006, 1009, 158 USPQ 275, 277 (CCPA 1968)). 

The Office also notes MPEP § 2144.01, that quotes In re Preda, 401 F.2d 825, 159 USPQ 
342, 344 (CCPA 1968) as stating "in considering the disclosure of a reference, it is proper to take 
into account not only specific teachings of the reference but also the inferences which one skilled 
in the art would reasonably be expected to draw therefrom." Further MPEP 2123, states that "a 
reference may be relied upon for all that it would have reasonably suggested to one having 
ordinary skill the art, including nonpreferred embodiments. Merck & Co. v. Biocraft 
Laboratories, 874 F.2d 804, 10 USPQ2d 1843 (Fed. Cir.), cert, denied, 493 U.S. 975 (1989). 
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For at least these reasons, the Office asserts the rejections of the claims as set forth 

below. 



4. Claims 1, 3-4 and 10-16 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Hong Su et al. ("Identification of Syntactically Similar DTD Elements for Schema 
Matching", The Second International Conference on Web-Age Information Management (Waim 
2001}, Xi'an, China, July 2001, pp. 1-13, hereafter referred to as "SchemaMatching") in view of 
Hong Su et al. ("XEM: Managing the Evolution of XML Documents", Eleventh International 
Workshop on Research Issues in Data Engineering (RIDE 2001) , Heidelberg, Germany, April 1- 
2, 2001, pp. 1-8, hereafter referred to as "XEM") and further in view of Hellman et al. (US 
Patent Application Publication No. 2004/0216030, filed via continuation on May 25, 2001 and 
published Oct. 28, 2004, hereafter referred to as "Hellman"). 



Independent claim 1 states: 

A method of document transformation comprising: 

a) modeling source XML document corresponding to a source schema as a source 
tree having a plurality of source nodes; 

b) modeling target XML document corresponding to a target schema as a target 
tree having a plurality of target nodes; and 

c) generating a sequence of transformation operations that transforms said 
source tree to said target tree, said sequence of transformation operations utilizing an 
extensible stylesheet language for transformations (XSLT) generator to translate the 
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sequence of transformation operations into an equivalent XSLT transformation script and 
utilize the transformation script to transform an input XML document corresponding to 
the source schema to the target XML document corresponding to the target schema. 

Regarding these limitations ... 

a) modeling source XML document corresponding to a source schema as a source tree 
having a plurality of source nodes; 

b) modeling target XML document corresponding to a target schema as a target tree having 
a plurality of target nodes; and 

SchemaMatching discloses DTD schema matching in the Abstract, discussing the 

matching of elements between two DTD schemas. SchemaMatching further discusses in 
Example 1 of page 2, the modeling of DTD schemas for a customer (i.e., source) and a client 
(i.e., target) as DTD graphs. Figure 1 of page 5 shows (arranged as tree data structures) the 
element graphs for the customer and client DTDs, and section "2.3 Construction of a Directed 
Acyclic Graph (DAG)" describes the process of creating the DAG, or tree, data structure. 

c) generating a sequence of transformation operations that transforms said source tree to 
said target tree, 

However, SchemaMatching does not explicitly disclose the generation of a sequence of 
transformation operations. XEM, though, teaches the application of a series of transformation 
operations in section "4 Completeness of DTD Change Operations" on pages 6-7, discussing a 
proof for the generation of a target DTD (e.g., G') from a source DTD (e.g., G) via a finite 
sequence of operations (e.g., "F()" ). XEM further discloses a working framework, dubbed 
"Marrow", the implemented the concepts disclosed by XEM, and was demonstrated at the ACM 
SIGMOD 2000. (See page 7 section "5 System Implementation: MARROW" and Footnote 1.) 
Additionally, XEM discusses the application of DTD change primitives to child nodes in order to 
ensure the validity of the target DTD in section "3.2 DTD Change Primitives". 
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It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of XEM for the benefit of SchemaMatching, because to do so would have 
allowed a designer to change a DTD without requiring change of underlying XML data, as 
taught by XEM in top left paragraph of page 2. These references were all applicable to the same 
field of endeavor, i.e., XML programming. 



said sequence of transformation operations utilizing an extensible stylesheet language for 
transformations (XSLT) generator to translate the sequence of transformation operations into 
an equivalent XSLT transformation script and utilize the transformation script to transform 
an input XML document corresponding to the source schema to the target XML document 
corresponding to the target schema. 

SchemaMatching docs not explicitly disclose a hardware implementation environment. 

Hellman, though, teaches the conversion of XML expressions into an XSLT script for 

transforming a source data schema into data conforming to a target data schema in paragraphs 

[0065] - [0066]. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of Hellman for the benefit of SchemaMatching in view of XEM, because 
to do so would have provided a tool for transforming a first and a second schema and have 
allowed companies to readily use each other's databases for sharing data, as taught by Hellman 
in paragraphs [0049] - [0050]. These references were all applicable to the same field of 
endeavor, i.e., XML programming. 
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Regarding dependent claim 3, SchemaMatching discloses matching leaf vertices (i.e., 
nodes of a tree) in section "3.1 Initial Leaf Vertices Matching" on pages 5-6, discussing 
operational steps for "Matching Criterion 1" between leaf nodes. Discussion of "Matching 
Criterion 2" in section "4 Detection of Hierarchically Equivalent Elements" on page 7, discloses 
a stricter set of rules for matching leaf nodes that includes consideration of the tree hierarchy to 
the nodes being matched. 

Regarding dependent claim 4, SchemaMatching does not explicitly disclose the 
generation of a sequence of transformation operations. XEM, though, teaches the application of 
a series of transformation operations in section "4 Completeness of DTD Change Operations" on 
pages 6-7, discussing a proof for the generation of a target DTD (e.g., G') from a source DTD 
(e.g., G) via a finite sequence of operations (e.g., "F()" ). XEM further discloses a working 
framework, dubbed "Marrow", the implemented the concepts disclosed by XEM, and was 
demonstrated at the ACM SIGMOD 2000. (See page 7 section "5 System Implementation: 
MARROW" and Footnote 1.) Additionally, XEM discusses the application of DTD change 
primitives to child nodes in order to ensure the validity of the target DTD in section "3.2 DTD 
Change Primitives". 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of XEM for the benefit of SchemaMatching, because to do so would have 
allowed a designer to change a DTD without requiring change of underlying XML data, as 
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These references were all applicable to the same 



Independent claim 10 states: 

A method of document transformation comprising: 

a) modeling a source schema of XML and a target schema of XML as a tree 
structure creating source tree and a target tree, said source tree having a plurality of 
source nodes, said target tree having a plurality of target nodes; and 

b) generating a sequence transformation operations that transforms said source 
XML document to said target XML document, wherein said plurality of source nodes of 
said source schema are matched and transformed to said plurality of target nodes in said 
target schema, said sequence of transformation operations utilizing an extensible 
stylesheet language for transformations (XSLT) generator to translate the sequence of 
transformation operations into an equivalent XSLT transformation script and utilize the 
transformation script to transform an input XML document corresponding to the source 
schema to the target XML document corresponding to the target schema. 



Regarding these limitations ... 

a) modeling a source schema of XML and a target schema of XML as a tree structure 
creating source tree and a target tree, said source tree having a plurality of source nodes, said 
target tree having a plurality of target nodes; and 

wherein said plurality of source nodes of said source schema are matched and transformed 
to said plurality of target nodes in said target schema, 

SchemaMatching discloses DTD schema matching in the Abstract, discussing the 

matching of elements between two DTD schemas. SchemaMatching further discusses in 

Example 1 of page 2, the modeling of DTD schemas for a customer (i.e., source) and a client 

(i.e., target) as DTD graphs. Figure 1 of page 5 shows (arranged as tree data structures) the 

element graphs for the customer and client DTDs, and section "2.3 Construction of a Directed 

Acyclic Graph (DAG)" describes the process of creating the DAG, or tree, data structure. 

SchemaMatching discloses matching leaf vertices (i.e., nodes of a tree) in section "3.1 Initial 

Leaf Vertices Matching" on pages 5-6, discussing operational steps for "Matching Criterion 1" 
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between leaf nodes. Discussion of "Matching Criterion 2" in section "4 Detection of 
Hierarchically Equivalent Elements" on page 7, discloses a stricter set of rules for matching leaf 
nodes that includes consideration of the tree hierarchy to the nodes being matched. 
SchemaMatching also discloses three exemplary methods of transforming DTD elements on 
page 3. 

b) generating a sequence transformation operations that transforms said source XML 
document to said target XML document, 

However, SchemaMatching does not explicitly disclose the generation of a sequence of 

transformation operations. XEM, though, teaches the application of a series of transformation 
operations in section "4 Completeness of DTD Change Operations" on pages 6-7, discussing a 
proof for the generation of a target DTD (e.g., G') from a source DTD (e.g., G) via a finite 
sequence of operations (e.g., "F()" ). XEM further discloses a working framework, dubbed 
"Marrow", the implemented the concepts disclosed by XEM, and was demonstrated at the ACM 
SIGMOD 2000. (See page 7 section "5 System Implementation: MARROW" and Footnote 1.) 
Additionally, XEM discusses the application of DTD change primitives to child nodes in order to 
ensure the validity of the target DTD in section "3.2 DTD Change Primitives". 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of XEM for the benefit of SchemaMatching, because to do so would have 
allowed a designer to change a DTD without requiring change of underlying XML data, as 
taught by XEM in top left paragraph of page 2. These references were all applicable to the same 
field of endeavor, i.e., XML programming. 
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said sequence of transformation operations utilizing an extensible stylesheet language for 
transformations (XSLT) generator to translate the sequence of transformation operations into 
an equivalent XSLT transformation script and utilize the transformation script to transform 
an input XML document corresponding to the source schema to the target XML document 
corresponding to the target schema. 

SchemaMatching does not explicitly disclose a hardware implementation environment. 

Hellman, though, teaches the conversion of XML expressions into an XSLT script for 

transforming a source data schema into data conforming to a target data schema in paragraphs 

[0065] - [0066]. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of Hellman for the benefit of SchemaMatching in view of XEM, because 
to do so would have provided a tool for transforming a first and a second schema and have 
allowed companies to readily use each other's databases for sharing data, as taught by Hellman 
in paragraphs [0049] - [0050]. These references were all applicable to the same field of 
endeavor, i.e., XML programming. 

Regarding dependent claim 11, SchemaMatching discloses matching nodes and 
selecting a best matching plan in phases numbered 3 and 4 on page 2 (immediately above the 
section labeled "2 DTD Data Model"). SchemaMatching also discloses distance (i.e., cost) and 
element overlap (i.e., data loss) in Example 4 of page 7, and the paragraph preceding Example 4, 
which discuss computing a number reflective of the amount of overlap of two graphs. 
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Regarding dependent claim 12, SchemaMatching does not explicitly disclose the 
generation of a sequence of transformation operations. XEM, though, teaches the application of 
a series of transformation operations in section "4 Completeness of DTD Change Operations" on 
pages 6-7, discussing a proof for the generation of a target DTD (e.g., G') from a source DTD 
(e.g., G) via a finite sequence of operations (e.g., "F()" ). XEM further discloses a working 
framework, dubbed "Marrow", the implemented the concepts disclosed by XEM, and was 
demonstrated at the ACM SIGMOD 2000. (See page 7 section "5 System Implementation: 
MARROW" and Footnote 1.) Additionally, XEM discusses the application of DTD change 
primitives to child nodes in order to ensure the validity of the target DTD in section "3.2 DTD 
Change Primitives". 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of XEM for the benefit of SchemaMatching, because to do so would have 
allowed a designer to change a DTD without requiring change of underlying XML data, as 
taught by XEM in top left paragraph of page 2. These references were all applicable to the same 
field of endeavor, i.e., XML programming. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of XEM for the benefit of SchemaMatching, because to do so would have 
allowed a designer to change a DTD without requiring change of underlying XML data, as 
taught by XEM in top left paragraph of page 2. These references were all applicable to the same 
field of endeavor, i.e., XML programming. 
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Regarding dependent claim 13, SchemaMatching discloses the use of source and target 
DTDs in phase number "1." above the section entitled "2 DTD Data Model", discussing 
modeling source and target DTDs as graphs. 

Regarding dependent claim 14, SchemaMatching discloses simplifying DTDs into a 
reduced DTD in section "2.1 Simplification Transformation on DTD", discussing, for example, a 
transformation that folds a group into a flattened representation. 

Regarding dependent claim 15, SchemaMatching discloses simplifying DTDs into a 
reduced DTD in section "2.1 Simplification Transformation on DTD", discussing, for example, a 
transformation that merges sub-elements having the same name in a content model. 

Regarding dependent claim 16, SchemaMatching does not explicitly disclose 
constraining node operations. XEM, though, teaches the well-known use of quantifier node 
notation, such as qmark "?", asterisk "*" and plus "+" in sub-section 2. Constraint Node" on 
page 3. XEM further discusses labelling in the third paragraph bleow the section header "2.2 
The DTD Data Model", discussing the labelling function / (i.e., "ell"). XEM discloses on pages 
3-6 various operations performed on DTD models. In section "2.2 The DTD Data Model", XEM 
sets forth how nodes are labelled and the notation used by one skilled in the art at the time of the 
invention. Section "3.2 DTD Change Primitives" sets forth various operations using that 
notation, including folding or flattening (see page 5 "5. flattenGroup(E, pos)") [it being obvious 
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that one performed the inverse of folding in order to unfold], and the changing of attributes 
[including relabeling] in section "3.2.3 Changes to an Attribute Type Definition" on page 6. 

When certain functions are performed is merely an obvious variant. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of XEM for the benefit of SchemaMatching, because to do so would have 
allowed a designer to change a DTD without requiring change of underlying XML data, as 
taught by XEM in top left paragraph of page 2. These references were all applicable to the same 
field of endeavor, i.e., XML programming. 

5. Claim 18 and 20-21 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Hong Su et al. ("Identification of Syntactically Similar DTD Elements for Schema Matching", 
The Second International Conference on Web-Age Information Management (Waim 2001) , 
Xi'an, China, July 2001, pp. 1-13, hereafter referred to as "SchemaMatching") in view of Hong 
Su et al. ("XEM: Managing the Evolution of XML Documents", Eleventh International 
Workshop on Research Issues in Data Engineering (RIDE 2001) , Heidelberg, Germany, April 1- 
2, 2001, pp. 1-8, hereafter referred to as "XEM") and further in view of Hellman et al. (US 
Patent Application Publication No. 2004/0216030, filed via continuation on May 25, 2001 and 
published Oct. 28, 2004, hereafter referred to as "Hellman") and Swamy et al. (US Patent No. 
6,874,141, filed Jun. 29, 2000 and issued Mar. 29, 2005, hereafter referred to as "Swamy"). 



Application/Control Number: 10/091,237 
Art Unit: 2162 



Page 15 



Independent claim 18 states: 

A computer system comprising: 
a processor; and 

a computer readable memory coupled to said processor and containing program 
instructions that, when executed, implement a method of document transformation 
comprising: 

a) modeling source XML document corresponding to a source schema as a source 
tree having a plurality of source nodes; 

b) modeling target XML document corresponding to a target schema as a target 
tree having a plurality of\target nodes; and 

c) generating a sequence of transformation operations that transforms said 
source tree said target tree, said sequence of transformation operations utilizing an 
extensible stylesheet language for transformations (XSLT) generator to translate the 
sequence of transformation operations into an equivalent XSLT transformation script and 
utilize the transformation script to transform an input XML document corresponding to 
the source schema to the target XML document corresponding to the target schema. 



Regarding these limitations ... 

a) modeling source XML document corresponding to a source schema as a source tree 
having a plurality of source nodes; 

b) modeling target XML document corresponding to a target schema as a target tree having 
a plurality of target nodes; and 

SchemaMatching discloses DTD schema matching in the Abstract, discussing the 

matching of elements between two DTD schemas. SchemaMatching further discusses in 
Example 1 of page 2, the modeling of DTD schemas for a customer (i.e., source) and a client 
(i.e., target) as DTD graphs. Figure 1 of page 5 shows (arranged as tree data structures) the 
element graphs for the customer and client DTDs, and section "2.3 Construction of a Directed 
Acyclic Graph (DAG)" describes the process of creating the DAG, or tree, data structure. 
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c) generating a sequence of transformation operations that transforms said source tree to 
said target tree. 

However, SchemaMatching does not explicitly disclose the generation of a sequence of 
transformation operations. XEM, though, teaches the application of a series of transformation 
operations in section "4 Completeness of DTD Change Operations" on pages 6-7, discussing a 
proof for the generation of a target DTD (e.g., G') from a source DTD (e.g., G) via a finite 
sequence of operations (e.g., "F()" ). XEM further discloses a working framework, dubbed 
"Marrow", the implemented the concepts disclosed by XEM, and was demonstrated at the ACM 
SIGMOD 2000. (See page 7 section "5 System Implementation: MARROW" and Footnote 1.) 
Additionally, XEM discusses the application of DTD change primitives to child nodes in order to 
ensure the validity of the target DTD in section "3.2 DTD Change Primitives". 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of XEM for the benefit of SchemaMatching, because to do so would have 
allowed a designer to change a DTD without requiring change of underlying XML data, as 
taught by XEM in top left paragraph of page 2. These references were all applicable to the same 
field of endeavor, i.e., XML programming. 

said sequence of transformation operations utilizing an extensible stylesheet language for 
transformations (XSLT) generator to translate the sequence of transformation operations into 
an equivalent XSLT transformation script and utilize the transformation script to transform 
an input XML document corresponding to the source schema to the target XML document 
corresponding to the target schema; 

SchemaMatching does not explicitly disclose a hardware implementation environment. 

Hellman, though, teaches the conversion of XML expressions into an XSLT script for 

transforming a source data schema into data conforming to a target data schema in paragraphs 

[0065] - [0066]. 
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It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of Hellman for the benefit of SchemaMatching in view of XEM, because 
to do so would have provided a tool for transforming a first and a second schema and have 
allowed companies to readily use each other's databases for sharing data, as taught by Hellman 
in paragraphs [0049] - [0050]. These references were all applicable to the same field of 
endeavor, i.e., XML programming. 

a processor; and 

a computer readable memory coupled to said processor and containing program 
instructions that, when executed, implement a method of document transformation 
comprising; 

SchemaMatching does not explicitly disclose a hardware implementation environment. 
Swamy, though, teaches a hardware implementation environment in Figure 15, disclosing a 
processor (#521) and memory units (#522, 527, 529, 531) coupled via a bus (#523) for executing 
applications (#536), including source to target schema transformations (Abstract). 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of Swamy for the benefit of SchemaMatching in view of XEM and 
Hellman, because to do so would have allowed one to compile a graphical representation of data 
transformations into an XSL stylesheet representation of the mapping, as taught by Swamy in 
col. 3 lines 19-25. These references were all applicable to the same field of endeavor, i.e., XML 
programming. 
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Regarding dependent claim 20, SchemaMatching discloses matching leaf vertices (i.e., 
nodes of a tree) in section "3.1 Initial Leaf Vertices Matching" on pages 5-6, discussing 
operational steps for "Matching Criterion 1" between leaf nodes. Discussion of "Matching 
Criterion 2" in section "4 Detection of Hierarchically Equivalent Elements" on page 7, discloses 
a stricter set of rules for matching leaf nodes that includes consideration of the tree hierarchy to 
the nodes being matched. 

Regarding dependent claim 21, SchemaMatching does not explicitly disclose the 
generation of a sequence of transformation operations. XEM, though, teaches the application of 
a series of transformation operations in section "4 Completeness of DTD Change Operations" on 
pages 6-7, discussing a proof for the generation of a target DTD (e.g., G') from a source DTD 
(e.g., G) via a finite sequence of operations (e.g., "F()" ). XEM further discloses a working 
framework, dubbed "Marrow", the implemented the concepts disclosed by XEM, and was 
demonstrated at the ACM SIGMOD 2000. (See page 7 section "5 System Implementation: 
MARROW" and Footnote 1.) Additionally, XEM discusses the application of DTD change 
primitives to child nodes in order to ensure the validity of the target DTD in section "3.2 DTD 
Change Primitives". 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of XEM for the benefit of SchemaMatching in view of Hellman and 
Swamy, because to do so would have allowed a designer to change a DTD without requiring 
change of underlying XML data, as taught by XEM in top left paragraph of page 2. These 
references were all applicable to the same field of endeavor, i.e., XML programming. 
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6. Claims 5-9 are rejected under 35 U.S.C. 103(a) as being unpatentable over Hong Su et 
al. ("Identification of Syntactically Similar DTD Elements for Schema Matching", The Second 
International Conference on Web- Age Information Management (Waim 2001) , Xi'an, China, 
July 2001, pp. 1-13, hereafter referred to as "SchemaMatching") in view of Hong Su et al. 
("XEM: Managing the Evolution of XML Documents", Eleventh International Workshop on 
Research Issues in Data Engineering (RIDE 2001) , Heidelberg, Germany, April 1-2, 2001, pp. 1- 
8, hereafter referred to as "XEM") and further in view of Hellman et al. (US Patent Application 
Publication No. 2004/0216030, filed via continuation on May 25, 2001 and published Oct. 28, 
2004, hereafter referred to as "Hellman") and Peter Buneman et al ("UnQL: A Query Language 
and Algebra for SemiStructured Data Based on Structural Recursion", The VLDB Journal Issue 
No. 9, Springer- Verlag, © 2000, pp. 76-1 10, hereafter referred to as "Buneman"). 

Regarding dependent claims 5-6 and 8-9, SchemaMatching discloses matching source 
and target nodes and generating a transformation between nodes in phases 3 and 4 on page 2, 
discussing the matching likelihood of component pairs" (phase 3) and producing a "best 
matching plan" in phase 4. However, SchemaMatching does not explicitly disclose computing 
for a sequence of transformation operations, such as unfolding. Buneman, though, teaches the 
calculation of value equivalence in performing operations on trees in section "4.1 value 
Equivalence" starting on page 88, discussing the determination of a value equivalence for a data 



Application/Control Number: 1 0/091 ,237 Page 20 

Art Unit: 2162 

graph d and the resulting graph from an unfold operation in the first and second paragraphs under 
the section heading. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of Buneman for the benefit of SchemaMatching in view of XEM and 
Hellman, because to do so would have allowed one to implement a value-based semistructured 
data model, as taught by Buneman in last paragraph on page 77. These references were all 
applicable to the same field of endeavor, i.e., XML programming. 

Regarding dependent claim 7, SchemaMatching does not explicitly disclose matching 
node labels. XEM, though, teaches the use of node labels in section "2.2 The DTD Data Model", 
discussing a labeling for node attributes. It was implicit in node matching that at least one node 
attribute must be matched, and it was a obvious variant at the time of the invention as to which 
attribute (e.g. label name) was matched between nodes. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of XEM for the benefit of SchemaMatching in view of Hellman and 
Buneman, because to do so would have allowed a designer to change a DTD without requiring 
change of underlying XML data, as taught by XEM in top left paragraph of page 2. These 
references were all applicable to the same field of endeavor, i.e., XML programming. 
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7. Claims 22-26 are rejected under 35 U.S.C. 103(a) as being unpatentable over Hong Su 
et al. ("Identification of Syntactically Similar DTD Elements for Schema Matching", The Second 
International Conference on Web- Age Information Management (Waim 2001) , Xi'an, China, 
July 2001, pp. 1-13, hereafter referred to as "SchemaMatching") in view of Hong Su et al. 
("XEM: Managing the Evolution of XML Documents", Eleventh International Workshop on 
Research Issues in Data Engineering (RIDE 2001) , Heidelberg, Germany, April 1-2, 2001, pp. 1- 

8, hereafter referred to as "XEM") and further in view of Hellman et al. (US Patent Application 
Publication No. 2004/0216030, filed via continuation on May 25, 2001 and published Oct. 28, 
2004, hereafter referred to as "Hellman") and Swamy et al. (US Patent No. 6,874,141, filed Jun. 
29, 2000 and issued Mar. 29, 2005, hereafter referred to as "Swamy") and Peter Buneman et al 
("UnQL: A Query Language and Algebra for SemiStructured Data Based on Structural 
Recursion", The VLDB Journal . Issue No. 9, Springer-Verlag, © 2000, pp. 76-1 10, hereafter 
referred to as "Buneman"). 

Regarding dependent claims 22-23 and 25-26, SchemaMatching discloses matching 
source and target nodes and generating a transformation between nodes in phases 3 and 4 on 
page 2, discussing the matching likelihood of component pairs" (phase 3) and producing a "best 
matching plan" in phase 4. However, SchemaMatching does not explicitly disclose computing 
for a sequence of transformation operations, such as unfolding. Buneman, though, teaches the 
calculation of value equivalence in performing operations on trees in section "4.1 value 
Equivalence" starting on page 88, discussing the determination of a value equivalence for a data 
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graph d and the resulting graph from an unfold operation in the first and second paragraphs under 
the section heading. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of Buneman for the benefit of SchemaMatching in view of XEM and 
further in view of Hellman and Swamy, because to do so would have allowed one to implement a 
value-based semistructured data model, as taught by Buneman in last paragraph on page 77. 
These references were all applicable to the same field of endeavor, i.e., XML programming. 

Regarding dependent claim 24, SchemaMatching does not explicitly disclose matching 
node labels. XEM, though, teaches the use of node labels in section "2.2 The DTD Data Model", 
discussing a labeling for node attributes. It was implicit in node matching that at least one node 
attribute must be matched, and it was a obvious variant at the time of the invention as to which 
attribute (e.g. label name) was matched between nodes. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the teachings of XEM for the benefit of SchemaMatching in view of Hellman, Swamy 
and Buneman, because to do so would have allowed a designer to change a DTD without 
requiring change of underlying XML data, as taught by XEM in top left paragraph of page 2. 
These references were all applicable to the same field of endeavor, i.e., XML programming. 
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Conclusion 

8. The prior art made of record and not relied upon is considered pertinent to applicant's 
disclosure. 

US Patent Application Publications 

Sampathkumar et al 2005/0086584 
Hellmanetal 2003/0163597 



Vedula et al 
Vedula et al 
Sundaresan 



US Patents 



7,159,185 
6,823,495 
6,487,566 



9. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 
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Contact Information 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Robert Stevens whose telephone number is (571) 272-4102. The 
examiner can normally be reached on M-F 6:00 - 2:30. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, John E. Breene can be reached on (571) 272-4107. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/Robert Stevens/ 
Examiner 
Art Unit 2162 

January 14, 2009 
/John Breene/ 

Supervisory Patent Examiner, Art Unit 2162 



